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Abstract 

In  this  paper,  we  investigate  the  behavior  of  the  various  algorithms  of  TCP,  the  internet  data 
transport  protocol,  over  wireless  links  with  correlated  packet  losses.  For  such  a  scenario,  we  show 
that  the  performance  of  NewReno  is  worse  than  the  performance  of  Tahoe  in  many  situations 
and  even  OldTahoe  in  a  few  situations  on  account  of  the  inefficient  fast  recovery  method  of 
NewReno.  We  also  show  that  random  loss  leads  to  significant  throughput  deterioration  when 
either  the  product  of  the  square  of  the  bandwidth-delay  ratio  and  the  loss  probability  when  in 
the  good  state  exceeds  1  or  the  product  of  the  bandwidth-delay  ratio  and  the  packet  success 
probability  when  in  the  bad  state  is  less  than  two.  The  performance  of  Sack  is  always  seen  to 
be  the  best  and  the  most  robust  thereby  arguing  for  the  implementation  of  TCP  SACK  over 
the  wireless  channel.  We  also  show  that  under  certain  conditions  the  performance  depends  not 
only  on  the  bandwidth-delay  product  but  also  on  the  nature  of  timeout  whether  coarse  or  fine. 
We  have  also  investigated  the  effects  of  reducing  the  fast  retransmit  threshold. 


1  Introduction 

The  transport  protocol  used  by  many  internet  based  applications  like  http,  ftp,  telnet  etc.  is  TCP 
(transmission  control  protocol).  TCP  is  a  reliable  end  to  end  window  based  transport  protocol 
designed  for  the  wireline  networks  characterized  by  negligible  random  packet  losses.  The  way  that 

‘This  research  was  supported  in  part  by  NSF  under  a  CAREER  award  NCR-9502614  and  by  the  AFOSR  under 
grant  95-1-0061. 

^A  partial  version  of  this  paper  appeared  in  Sigmetrics99  Atlanta. 
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TCP  works  is  that  it  keeps  increasing  the  sending  rate  of  packets  as  long  as  no  packets  are  lost. 
When  packet  losses  occur,  for  e.g.  due  to  the  network  becoming  congested,  TCP  decreases  the 
sending  rate.  Thus,  basically  TCP  infers  that  every  packet  loss  is  due  to  congestion  and  hence 
backs  off  in  the  form  of  reducing  the  send  window.  Extending  TCP  as  used  over  the  wireline  links 
to  the  wireless  links  also,  may  not  be  an  efficient  solution  due  to  the  different  characteristics  of 
the  wireline  and  the  wireless  links.  This  is  because  wireless  networks  are  characterized  by  bursty 
and  high  channel  error  rates  unlike  the  wireline  networks.  Due  to  this  the  throughput  of  a  TCP 
connection  over  a  wireless  link  suffers.  In  spite  of  this,  the  TCP  protocol  is  still  used  to  transfer 
data  over  the  wireless  link  though  a  lot  of  attention  is  currently  being  given  to  the  design  of  a  better 
protocol  over  the  wireless  link  [16,  2,  3,  14,  4,  7].  Because  of  the  difficulty  of  modelling  the  TCP 
protocol  analytically,  many  of  these  studies  have  been  simulation  based.  On  the  other  hand,  it  is 
not  possible  to  obtain  insight  into  the  effects  of  particular  parameters  on  the  behavior  of  the  TCP 
protocol  using  simulations  of  specific  settings.  Further,  investigations  to  improve  TCP  or  design 
a  better  transport  protocol  can  become  less  cumbersome  given  a  simple  and  accurate  analytical 
model  for  TCP. 

The  first  step  towards  the  design  of  a  better  transport  protocol  for  the  wireless  networks  has 
to  be  a  better  understanding  of  the  way  TCP  works  over  the  wireless  links.  This  would  reveal  the 
reasons  for  the  inefficiency  of  TCP  over  wireless  links.  In  order  to  get  a  deeper  understanding  of 
the  way  that  TCP  works  over  wireless  links  there  has  been  some  effort  recently  on  the  analytical 
study  of  TCP  over  wireless  links  [10,  11,  17,  12].  Typically,  the  random  losses  on  the  wireless  link 
are  modeled  using  two  different  methods.  In  case  of  a  simple  model  called  the  iid  model,  it  can 
be  assumed  that  each  packet  is  lost  with  a  certain  constant  probability  independent  of  the  other 
packets,  which  corresponds  to  a  Bernoulli  loss  model.  The  second  model  namely  the  correlated 
packet  loss  model  is  more  realistic  and  it  does  not  model  the  packet  losses  as  being  independent  of 
each  other  but  does  address  the  correlation  between  the  losses  of  different  packets. 

[10]  deals  with  the  effects  of  iid  packet  losses  on  TCP  performance.  They  address  the  TCP 
versions  Tahoe,  Reno  and  NewReno  but  only  in  the  context  of  a  local  network  scenario.  They  also 
evaluate  the  various  protocol  features  such  as  fast  retransmit  and  fast  recovery.  But  contrary  to 
the  actual  situation,  the  packet  transmission  times  are  assumed  to  be  exponentially  distributed  as 
is  the  transmission  time  of  the  packet  on  the  lossy  link.  Further,  they  also  model  the  congestion 
avoidance  phase  probabilistically  in  which  each  ack  causes  the  window  to  be  incremented  by  1  with 
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a  certain  probability.  Note  that  both  these  assumptions  are  untrue  but  have  to  be  resorted  to  in 
the  approach  taken  by  them  so  as  to  carry  out  the  mean  cycle  time  analysis.  In  this  study  the 
authors  also  consider  the  less  frequent  case  where  the  size  of  the  receiver  window  is  the  constraint 
on  the  sender’s  window  increase  and  not  the  bandwidth  delay  product  of  the  link.  Thus,  this  study 
precludes  the  study  of  the  basic  TCP  mechanism  whereby  the  window  size  is  increased  until  there 
is  a  loss  due  to  congestion.  This  loss  is  caused  on  account  of  the  bandwidth  delay  constraint.  In 
[13]  only  OldTahoe  is  considered  over  a  link  with  iid  losses.  [12]  also  considers  Tahoe  and  Reno  in  a 
regime  where  the  bandwidth-delay  product  of  the  network  is  high  compared  to  the  buffering  in  the 
network.  The  key  result  that  they  provide  is  the  characterization  of  a  condition  under  which  the 
throughput  over  the  lossy  link  degrades  significantly.  They  show  using  approximate  analysis  that 
random  independent  packet  loss  leads  to  significant  throughput  deterioration  when  the  product  of 
the  loss  probability  and  the  square  of  the  bandwidth-delay  product  is  larger  than  one. 

[11]  considers  the  behavior  of  TCP  Tahoe  and  OldTahoe  in  the  presence  of  correlated  packet 
losses.  The  results  obtained  though  are  applicable  only  in  case  of  very  low  bandwidth  wireless 
links.  More  emphasis  is  also  placed  on  analyzing  a  link  layer  solution,  of  hiding  the  losses  from  the 
transport  layer  by  link  layer  retransmissions,  to  the  problem  faced  by  TCP  over  the  wireless  link. 
The  approach  used  is  also  similar  to  the  approach  used  in  [10]  and  hence  suffers  from  the  drawbacks 
noted  earlier.  [17]  which  deals  with  TCP  OldTahoe  assuming  a  correlated  loss  model,  also  fails 
to  capture  many  interesting  phenomena.  The  approach  followed  by  them  requires  enumerating 
the  transmission  time,  acknowledgment  time  and  timeout  time  of  every  packet  in  a  cycle.  This  is 
computationally  cumbersome  in  case  of  the  analysis  of  links  with  large  bandwidth  delay  products 
since  in  this  case  large  number  of  packets  have  to  be  accounted  for.  Further,  this  approach  cannot 
be  taken  to  model  the  fast  retransmit  and  fast  recovery  mechanisms  present  in  the  newer  TCP 
versions  like  Tahoe,  Reno,  NewReno  and  Sack. 

It  should  be  pointed  out  that  all  the  analytical  studies  and  many  of  the  simulation  studies 
reported  have  been  concerned  with  just  a  single  TCP  connection.  In  addition  to  modeling  of  the 
interaction  between  multiple  TCP  flows  being  notoriously  difficult,  the  main  reason  for  this  is  to 
develop  insight  into  the  interaction  between  random  packet  losses  and  the  TCP  dynamic  window 
adjusting  mechanism.  Note  that  while  considering  single  connections  if  one  were  to  ignore  the 
congestion  control  functions  then  the  solution  would  be  trivial.  Some  form  of  selective  repeat  ARQ 
with  a  window  large  enough  to  exceed  the  bandwidth  delay  product  of  the  link  would  be  the  best 
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solution.  It  is  quite  obvious  that  such  a  scheme  would  be  a  disaster  when  many  connections  are 
considered.  Further,  with  the  goal  being  to  use  the  results  of  studies  involving  single  flows  to  design 
improvements  in  TCP  for  use  by  multiple  users,  congestion  control  functions  would  also  have  to  be 
considered  and  hence  the  above  trivial  solution  is  ruled  out. 

In  this  paper,  we  analyze  the  behavior  of  the  different  TCP  algorithms  OldTahoe,  Tahoe, 
NewReno  and  Sack  under  conditions  whereby  the  wireless  channel  is  subjected  to  the  more  realistic 
case  of  correlated  packet  losses.  Since,  the  main  aim  of  this  study  is  to  address  the  behavior  of 
the  different  TCP  versions  under  different  conditions  of  the  wireless  channel  we  do  not  consider 
the  effects  of  multiple  flows  at  all.  This,  in  fact  could  be  a  subject  of  future  work.  In  this  paper 
we  show  that  in  certain  circumstances  characterized  by  bursty  loss  conditions,  the  performance 
of  NewReno  can  lag  behind  the  performance  of  Tahoe.  This  performance  gap  can  worsen  against 
NewReno  as  the  bandwidth-delay  product  increases.  We  also  show  that  the  performance  of  Sack 
is  the  best  under  all  conditions,  though  at  loss  rates  characterized  by  very  small  durations  of  good 
periods  the  performance  of  the  different  versions  is  equally  bad.  We  also  derive  conditions  under 
which  significant  throughput  deterioration  occurs  under  correlated  loss  conditions.  Investigation 
into  the  effects  of  reducing  the  fast  retransmit  threshold  as  well  as  using  finer  timeout  intervals  is 
also  carried  out  and  we  show  that  these  incremental  changes  to  the  TCP  versions  are  effective  only 
in  case  of  lossy  conditions. 

The  plan  of  the  paper  is  as  follows.  In  section  2,  we  describe  briefly  the  various  TCP  versions. 
In  section  3,  we  specify  the  correlated  loss  model  in  detail.  In  section  4,  we  explain  the  approach 
that  we  take  in  order  to  study  the  behavior  of  the  different  TCP  versions  under  different  wireless 
channel  conditions.  In  Section  5  we  characterize  the  throughput  of  the  different  TCP  algorithms 
as  a  function  of  the  wireless  channel  parameters.  Section  6  deals  with  the  analytical  study  of 
the  performance  of  the  different  TCP  versions  under  various  conditions.  Finally  conclusions  are 
presented  in  Section  7. 

2  TCP  Versions 

We  next  look  briefly  at  the  way  the  receiver  and  transmitter  function  in  case  of  a  transport  protocol 
like  the  TCP.  The  receiver  sends  back  an  ack  for  every  packet  received  from  the  transmitter  *.  The 

*For  ease  of  description  we  ignore  variations  like  acknowledging  every  other  packet 
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acks  convey  information  about  the  next  expected  packet  sequence  that  the  receiver  expects.  Note 
that  if  packet  m  is  lost  and  packets  after  m  get  through,  then  the  receiver  sends  back  duplicate  acks 
all  conveying  information  that  the  receiver  expects  packet  with  sequence  number  m.  The  number 
of  duplicate  acks  depends  on  the  number  of  packets  after  m  that  the  receiver  gets.  The  acks  are 
cumulative  in  that  an  ack  carrying  sequence  number  k,  acknowledges  all  data  packets  upto  k.  The 
receiver  presents  packets  in  sequence  to  the  user.  Hence  any  packets  received  out  of  sequence  are 
stored  in  a  buffer  maintained  by  the  receiver  with  a  maximum  size  corresponding  to  W^ec  packets. 
The  acks  also  carry  information  about  the  size  of  the  buffer  at  the  receiver.  The  transmitter  window 
strategy  guarantees  that  no  more  than  W^ec  packets  will  be  in  transit. 

The  transmitter  operates  on  a  window  based  transmission  strategy.  At  any  time  t,  the  trans¬ 
mitter  knows  the  packets  that  have  been  successfully  acked  by  the  receiver.  Let  A{t)  correspond 
to  a  window  edge  of  packets  such  that  acks  for  all  packets  to  the  left  of  A{t)  have  been  received  at 
the  sender  while  the  ack  for  the  packet  to  the  immediate  right  of  A{t)  has  not  been  received  by  the 
sender  at  time  t.  Further,  the  transmitter  also  has  a  window  W (t)  associated  at  time  t  such  that 
only  A{t)  +  W (t)  packets  are  allowed  to  be  outstanding  (without  any  acks  received  for  those  pack¬ 
ets)  at  time  t.  On  the  receipt  of  acks,  A{t)  advances  while  the  window  adaptation  policy  followed 
causes  W  (t)  to  increase  in  a  predetermined  fashion.  Loss  of  packets  is  detected  by  the  transmitter 
either  by  a  timeout  or  by  the  receipt  of  duplicate  acks  sent  by  the  receiver.  In  the  wireline  network 
loss  of  packets  typically  signals  congestion.  Hence,  on  detection  of  a  packet  loss,  the  window  W (t) 
is  decreased  in  a  fashion  determined  by  the  window  adaptation  policy  and  transmission  restarts  by 
resending  the  lost  packet.  Note  that  A{t)  does  not  advance  in  such  a  situation.  Note  also  that  W (t) 
cannot  increase  beyond  a  minimum  of  Wrec  or  Wm  where  Wm  is  the  maximum  possible  window 
size  allowable  on  account  of  the  constraint  on  the  sum  of  the  bandwidth  delay  product  and  the 
buffer  size.  In  the  sequel,  we  assume  that  only  Wm  restricts  the  window  size  while  Wrec  does  not, 
i.e.  Wrec  >  Wm-  The  case  where  Wrec  <  Wm  can  also  be  addressed  using  our  approach  but  we  do 
not  do  it  here  for  lack  of  space. 

Thus  as  can  be  seen,  the  window  adaptation  procedure  depends  on  the  policy  followed.  Based 
on  the  policy  followed,  we  have  different  TCP  algorithms.  We  next  explain  the  different  TCP 
algorithms  that  we  study.  Each  differs  on  the  response  in  the  form  of  window  size  decrease  to  one 
or  more  packet  drops  and  the  fashion  of  window  increases  on  no  packet  drops.  The  algorithms 
are  of  5  types  namely,  TCP  OldTahoe,  TCP  Tahoe,  TCP  Reno,  TCP  NewReno  and  TCP  Sack. 
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There  are  also  other  TCP  algorithms  like  TCP  Vegas  but  we  do  not  concern  ourselves  with  them 
in  the  rest  of  the  paper  and  hence  do  not  describe  them  here.  The  window  adaptation  procedure 
for  the  different  TCP  versions  was  originally  proposed  and  developed  by  Van  Jacobson  [8].  The 
description  next  follows  that  of  [6]  and  [12], 

Data  exchange  using  a  transport  protocol  involves  a  session  set  up  phase,  a  data  transfer  phase 
and  a  session  tear  down  phase.  Since,  in  this  paper  we  are  interested  only  in  the  bulk  throughput 
performance,  we  describe  and  model  only  the  data  transfer  phase  of  the  protocol  which  dominates 
the  resulting  performance.  We  first  describe  the  basic  window  adaptation  procedure  common  to 
all  TCP  versions  and  then  look  at  the  specific  congestion  control  and  data  loss  recovery  protocols 
implemented  in  the  different  TCP  versions.  At  each  time  t,  we  denote  the  transmitter’s  congestion 
window  by  W  (t)  and  a  threshold  called  the  slow  start  threshold  by  uj{t).  These  are  defined  for  all 
the  protocol  versions  at  all  times.  Hence,  we  have 

•  if  VP  (t)  <  uj{t),  each  new  ack  from  the  receiver  results  in  W (t)  being  incremented  by  1.  This 
constitutes  the  slow  start  phase.  Thus  this  results  in  the  window  size  doubling  every  round 
trip  time  during  this  phase. 

•  if  W{t)  >  uj{t),  each  ack  for  a  new  packet  results  in  W{t)  being  increased  by  '^l\W{t)\  as 
long  as  the  congestion  window  W (t)  is  less  than  the  receiver  window.  If  W  (t)  equals  the 
receiver  window  size,  then  it  remains  unchanged  on  receipt  of  a  new  ack.  This  constitutes 
the  congestion  avoidance  phase.  Thus,  this  results  in  the  window  size  increasing  by  one 
every  round  trip  time  during  this  phase  provided  the  congestion  window  size  is  less  than  the 
receiver  window  size  . 

•  if  timeout  occurs  at  the  transmitter,  then  set  W{t'^)  =  1  and  =  L^(i)/2j  and  retrans¬ 

mission  starts  from  the  first  lost  packet  detected 

If  a  packet  is  lost  or  damaged  while  in  transit  from  the  sender  to  the  receiver  then  no  ack  cor¬ 
responding  to  this  packet  is  issued  and  this  packet  will  have  to  be  retransmitted.  But  in  order 
to  determine  when  to  retransmit  a  timer  is  associated  with  every  packet  when  it  is  sent.  If  the 
timer  expires  before  the  packet  is  acknowledged,  then  the  sender  must  retransmit.  But  a  problem 
that  arises  is  how  to  determine  the  value  of  the  timer.  Using  a  very  small  value  as  well  as  using  a 
very  large  value  for  the  retransmission  timer  both  create  problems.  The  approach  normally  taken 
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is  to  have  an  adaptive  scheme  whereby  an  exponential  smoothing  technique  is  used  to  estimate 
the  round  trip  time  of  the  connection.  The  variability  in  the  estimate  in  the  form  of  mean  devi¬ 
ation  is  then  used  along  with  the  estimated  round  trip  time  to  arrive  at  a  dynamic  estimate  of 
the  value  of  the  retransmit  timer  [8].  Further,  many  implementations  then  convert  the  calculated 
round  trip  time  in  terms  of  a  coarse  timer  granularity  of  0.5  seconds.  Hence,  it  is  expected  that 
whenever  a  packet  is  not  acked  within  this  interval  the  probability  that  it  is  lost  is  far  greater  than 
the  probability  that  it  is  delayed  for  so  long  and  in  the  rest  of  this  work  we  do  neglect  the  latter 
possibility.  Thus,  timeouts  always  imply  packet  loss.  Further,  we  also  take  the  approach  that  only 
one  retransmission  timer  is  maintained  for  an  entire  window  of  packets.  If  an  ack  is  received  then 
the  appropriate  packets  are  removed  from  the  active  window  and  the  timer  is  reset.  If  the  timer 
goes  off  without  the  expected  ack  being  received,  then  retransmit  the  packet  at  the  front  of  the 
window  and  reset  the  timer.  Of  course,  it  has  to  be  remarked  that  the  TCP  standard  does  allow 
other  possible  implementations  but  we  do  not  consider  those  either  because  the  other  possibilities 
are  more  complex  to  implement  or  because  the  other  possibilities  are  less  efficient  than  the  option 
that  we  consider.  We  next  provide  version  specific  details  of  the  different  TCP  versions. 

TCP  Old  Tahoe: [8]  The  window  adaptation  is  as  given  above.  A  lost  packet  is  always  detected 
by  timeout.  Hence,  after  a  packet  loss  the  transmitter  has  to  wait  for  the  timeout  which  is  generally 
coarse  (timer  interval  in  increments  of  500ms). 

TCP  Tahoe:  [6]  In  contrast  to  the  case  of  Old  Tahoe  where  every  packet  loss  is  detected  by  a 
timeout,  in  Tahoe  if  the  number  of  duplicate  acks  equalling  If  are  received  by  the  sender,  the  sender 
behaves  as  if  timeout  has  occurred  and  begins  retransmission  of  the  packet  perceived  to  be  lost.  It 
is  to  be  remarked  here  that  a  duplicate  ack  signifies  either  that  the  packet  following  the  correctly 
acked  packet  was  delayed  so  that  it  ultimately  arrived  out  of  order  or  that  the  packet  was  lost.  In 
the  former  case  the  packet  does  ultimately  reach  the  receiver  and  the  sender  should  not  retransmit 
this  packet.  In  the  latter  case  the  arrival  of  a  duplicate  ack  serves  as  an  early  warning  that  a  packet 
is  lost.  In  order  to  make  sure  that  we  have  a  case  of  a  lost  packet  rather  than  a  reordered  packet 
Jacobson  [8]  recommends  that  a  TCP  sender  wait  until  it  receives  three  duplicate  acks  to  the  same 
packet.  Thus  in  practical  implementations  the  value  of  If  is  taken  as  3.  This  is  because  it  is  seen 
that  for  such  a  value  of  If,  it  is  highly  likely  that  the  following  packet  is  lost  and  not  reordered. 

The  sender  window  and  slow  start  threshold  are  as  given  above.  This  method  of  detecting 
packet  loss  on  the  basis  of  the  duplicate  acks  is  called  the  fast  retransmit  procedure.  As  is  obvious. 
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this  can  lead  to  higher  channel  utilization  and  better  throughput  which  can  be  especially  significant 
when  dealing  with  coarse  timers.  Note  that  the  strategy  followed  to  recover  from  lost  data  in  case 
of  TCP  Tahoe  is  to  retransmit  packets  that  might  already  have  been  successfully  delivered. 

TCP  Reno:  [6]  This  version  modified  the  fast  retransmit  operation  to  include  fast  recovery. 
Once  the  packet  loss  is  detected  by  the  fast  retransmit  procedure,  the  sender  retransmits  the  packet 
deemed  to  be  lost  and  reduces  its  congestion  window  by  half.  Now,  instead  of  entering  the  slow- 
start  phase,  the  sender  uses  additional  incoming  acks  to  clock  subsequent  outgoing  packets.  Thus, 
if  the  packet  loss  was  at  a  window  of  cr,  then  =  [cr/2j  and  W (t~^)  =  the  addition 

of  Q  being  done  since  Q  packets  have  successfully  left  the  network  leading  to  the  Q  duplicate  acks. 

Now  after  retransmitting  only  the  first  lost  packet,  the  sender  waits  for  the  ack  of  the  retrans¬ 
mitted  (lost)  packet.  If  the  sender  receives  any  more  duplicate  acks  while  waiting  for  the  ack  of 
the  retransmitted  packet,  W (t)  is  increased  by  1  for  each  duplicate  ack  received.  Thus  the  sender 
’’inflates”  its  window  by  the  number  of  duplicate  acks  received.  After  half  a  window  of  duplicate 
acks  are  received,  the  sender  transmits  a  new  packet  for  each  additional  duplicate  ack  received.  In 
other  words,  until  [cr/2j  +  number  of  duplicate  acks  received  exceeds  cr,  the  sender  cannot  transmit 
any  more  new  packets.  Upon  receipt  of  an  ack  for  new  data  (recovery  ack)  the  sender  exits  fast 
recovery  and  starts  transmission  with  a  window  of  W  (U*")  =  =  Lcr/2J- 

When  a  single  packet  is  dropped  from  a  window  of  data  then  the  ack  for  the  first  retransmission 
will  complete  the  recovery  as  is  obvious  from  above.  But,  if  there  were  multiple  packet  losses  from 
a  window  of  data  then  the  ack  for  the  first  retransmitted  packet  leads  to  a  partial  ack.  A  partial 
ack  takes  out  the  sender  from  fast  recovery  and  the  usable  window  is  deflated  back  to  the  size  of 
the  congestion  window.  If  the  resulting  window  size  is  sufficient  to  permit  the  sender  to  transmit 
additional  packets  that  can  elicit  further  duplicate  acks  then  the  sender  may  enter  fast  recovery 
again  and  repeat  the  process  for  the  next  lost  packet.  But  if  the  number  of  duplicate  acks  are 
insufficient,  then  the  recovery  stalls  and  a  timeout  has  to  be  waited  for.  After  a  timeout  the  basic 
algorithm  is  followed. 

The  strategy  followed  by  the  Reno  sender  to  recover  from  losses  is  to  retransmit  at  most  one 
dropped  packet  per  round  trip  time.  For  a  single  packet  lost  from  a  data  window,  Reno  significantly 
improves  upon  the  behavior  of  Tahoe  but  with  multiple  packet  losses  from  a  data  window,  Reno 
suffers  from  serious  performance  problems  [6,  12]. 

TCP  New- Reno:  [6]  This  version  addresses  the  problem  faced  by  Reno  when  multiple  packets 
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are  lost  from  a  window  of  data.  In  Reno  receipt  of  partial  acks  takes  the  sender  out  of  fast 
recovery.  In  contrast,  the  NewReno  sender  does  not  get  out  of  fast  recovery  on  the  receipt  of  partial 
acks.  Instead,  partial  acks  are  treated  as  an  indication  that  the  packet  immediately  following  the 
acknowledged  packet  has  been  lost  and  should  be  retransmitted.  Thus,  when  multiple  packets 
are  lost  from  a  single  window  of  data,  NewReno  can  recover  without  a  retransmission  timeout, 
retransmitting  one  lost  packet  per  round-trip  time  until  all  lost  packets  from  that  window  have  been 
retransmitted  [6].  Of  course,  if  the  number  of  packets  lost  is  such  that  the  sender  cannot  enter  the 
fast  retransmit  phase,  then  a  timeout  has  to  be  resorted  to.  The  sender  remains  in  fast  recovery 
until  all  of  the  data  outstanding  when  fast  recovery  was  initiated  has  been  acknowledged. 

Since  NewReno  addresses  the  shortcomings  of  Reno,  it  is  obvious  that  Reno  can  never  better 
the  performance  shown  by  NewReno.  Hence,  in  the  rest  of  the  paper,  we  do  not  concern  ourselves 
with  Reno.  Another  reason  for  this  is  also  that  it  has  been  shown  for  multiple  losses,  Reno  can 
perform  worse  than  Tahoe  [6,  12]. 

TCP  Sack:  [6]  The  Sack  (selective  ack)  version  of  TCP  that  we  consider  is  a  conservative 
extension  of  Reno  in  that  they  use  the  same  policies  for  the  window  adaptation.  Each  ack  received 
by  the  sender  contains  information  about  any  non-contiguous  set  of  data  that  has  been  received 
and  queued  at  the  receiver.  Prom  this  the  sender  is  able  to  infer  the  different  packets  lost.  The 
Sack  sender  enters  fast  recovery  on  receiving  If  duplicate  acks.  The  actual  implementation  during 
fast  recovery  differs  from  the  Reno  implementation  but  the  overall  idea  is  the  same  and  hence  we 
do  not  describe  this  here  for  lack  of  space.  Details  about  the  actual  implementation  can  be  found 
in  [6].  On  receiving  partial  acks,  the  sender  does  not  exit  fast  recovery  just  like  in  NewReno.  But  a 
difference  with  NewReno  is  that  since  the  sender  has  more  information  about  the  different  packets 
lost,  it  is  not  constrained  to  retransmit  at  most  one  dropped  packet  per  round  trip  time  as  NewReno 
is.  The  sender  exits  fast  recovery  when  a  recovery  ack  is  received.  Even  here,  when  the  sender  is 
unable  to  enter  the  fast  retransmit  phase  due  to  lack  of  adequate  duplicate  acks,  timeout  has  to  be 
resorted  to. 

In  the  analysis  though,  we  ignore  the  fact  that  on  successive  timeouts  the  actual  value  of  the 
timeout  is  increased  exponentially.  Further  for  the  purpose  of  simplifying  the  analysis,  we  also 
assume  that  packets  retransmitted  during  fast  recovery  are  not  dropped.  As  a  result  it  is  to  be 
kept  in  mind  that  our  analysis  is  less  conservative  and  hence  gives  optimistic  values  compared  to 
the  actual  implementations  during  regimes  of  high  loss  probability.  We  would  also  like  to  remark 
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that  it  is  very  much  possible  using  our  approach  to  give  up  these  assumptions  at  the  cost  of 
higher  complexity.  Since  these  assumptions  affect  the  performance  only  in  the  region  of  high  loss 
probability  where  the  efficiency  is  already  very  low,  we  choose  to  reduce  complexity  by  making 
these  assumptions.  Note  also  that  these  approximations  done  to  simplify  the  analysis  in  no  way 
affect  the  results  that  we  obtain  in  this  paper.  As  done  in  case  of  the  other  studies,  we  assume  that 
acks  are  not  lost.  This  is  justified  because  of  the  fact  that  the  ack  packets  have  a  very  small  loss 
probability  due  to  the  small  size  of  the  packets.  Further  because  of  the  cumulative  nature  of  acks, 
the  only  consequence  of  ack  losses  is  increased  burstiness  on  the  forward  path  [15].  Our  description 
above  of  the  different  TCP  versions  has  been  very  brief.  Readers  requiring  more  details  can  refer 
to  [6]. 


3  Loss  Models 


It  is  well  known  that  mobile  radio  channels  in  an  actual  physical  environment  are  subject  to 
multipath  fading.  This  multipath  fading  process  can  be  slowly  varying  for  typical  user  speeds  and 
carrier  frequencies  in  a  mobile  environment.  Due  to  this  the  assumption  of  iid  packet  losses  as  is 
generally  done  is  not  entirely  true.  Hence,  we  consider  a  model  incorporating  correlated  losses  as 
we  specify  next. 

The  multipath  fading  process  in  a  mobile  environment  follows  a  Rayleigh  distribution  [9].  The 
issue  of  modelling  a  correlated  Rayleigh  fading  channel  by  means  of  a  simple  two  state  Markov 
chain  has  been  addressed  in  [11]  from  where  the  description  next  is  adapted.  The  two  states  that 
we  consider  are  the  ’’Good”  state  and  the  ’’Bad”  state.  We  assume  that  the  packet  succeeds  with 
probability  1  while  in  the  good  state  and  is  lost  with  probability  1  while  in  the  bad  state.  The 
transition  probability  matrix.  Cm,  of  the  simple  two  state  Markov  chain  is  then  given  by 


C„ 


\  1-/3; 


(1) 


The  chain  is  assumed  to  be  embedded  at  the  beginnings  of  packet  transmissions.  Thus,  if  a  number 
of  packets  is  being  transmitted  back  to  back,  and  if  the  channel  is  in  a  Good  state  when  a  packet  is 
about  to  be  transmitted  then  this  packet  will  be  successful  and  the  next  packet  will  be  successful 
or  unsuccessful  with  probabilities  1  —  a  and  a  respectively.  This  model  which  is  commonly  adopted 
in  wireless  fading  channels  [11,  17,  5]  tracks  fading  but  excludes  impairments  such  as  path  loss  and 
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shadowing  which  vary  on  a  much  longer  time  scale.  These  phenomena  are  assumed  to  be  taken  care 
of  by  power  control  mechanisms  and  hence  are  not  considered.  Thus,  given  a  and  (5  the  channel 
properties  are  completely  characterized.  Further,  the  steady  state  properties  of  the  chain  are  then 
given  by  ttg  and  ttb  which  symbolize  the  steady  state  probability  that  the  channel  is  in  the  good 
state  and  bad  state  respectively.  These  are  given  by 

(5  a 

Of  “h  p  Of  “h  p 

Note  that  the  average  duration  of  the  bad  state  is  given  by  1//3  while  the  average  duration  of 
the  good  state  is  given  by  l/a  slots  or  packets  since  we  assume  that  each  slot  corresponds  to  the 
transmission  time  of  a  packet. 

4  Approach 

The  behavior  of  the  different  TCP  algorithms  is  analyzed  based  on  the  concept  of  packet  trains 
which  we  introduce  next.  For  ease  of  explanation  we  consider  TCP  NewReno.  A  NewReno  sender 
when  sending  new  data  is  generally  either  in  the  slow  start  phase  or  the  congestion  avoidance  phase. 
The  loss  of  a  packet  in  either  of  these  phases  is  subsequently  followed  by  mechanisms  to  recover 
the  lost  packet  (s).  A  NewReno  sender  uses  the  fast  retransmit  mechanism  whereby  the  arrival  of 
a  certain  number  of  duplicate  acks  signals  a  packet  loss.  Of  course  if  not  enough  duplicate  acks  as 
required  by  the  fast  retransmit  mechanism  arrive  back  at  the  sender,  then  a  timeout,  which  is  the 
non-arrival  of  the  ack  of  a  packet  within  a  certain  time  interval,  is  taken  as  an  indication  of  the 
packet  loss.  Following  the  detection  of  a  packet  loss  through  the  fast  retransmit  mechanism  the 
NewReno  transmitter  resorts  to  the  fast  recovery  mechanism  whereby  the  window  size  is  reduced 
by  half  and  the  sender  uses  additional  incoming  acks  to  clock  outgoing  packets.  The  fast  recovery 
mechanism  concludes  successfully  when  all  the  lost  packets  have  been  recovered  and  this  is  followed 
by  the  congestion  avoidance  mechanism.  Of  course  if  a  retransmit  timeout  has  to  be  resorted  to, 
then  the  sender  always  starts  in  the  slow  start  phase  after  the  timeout  interval. 

Hence,  the  operation  of  a  NewReno  transmitter  can  be  considered  in  terms  of  cycles.  A  cycle 
begins  with  either  the  slow  start  phase  or  the  congestion  avoidance  phase  following  the  detection  of 
a  packet  loss.  The  cycle  ends  either  with  the  successful  conclusion  of  the  fast  recovery  mechanism 
or  on  the  basis  of  the  retransmit  timeout  mechanism.  This  timeout  can  occur  due  to  the  absence 
of  the  fast  recovery  mechanism.  The  fast  recovery  mechanism  may  be  absent  because  of  the  lack 


11 


of  adequate  duplicate  acks  to  infer  packet  loss  thereby  causing  the  fast  retransmit  mechanism  to 
fail.  Thus  a  typical  cycle  in  case  of  New  Reno  can  start  in  the  congestion  avoidance  phase,  have 
the  fast  recovery  phase  and  end  on  the  conclusion  of  the  fast  recovery  phase  because  all  the  packets 
transmitted  during  the  fast  recovery  stage  have  been  successful. 

Thus,  every  cycle  can  be  considered  to  have  three  stages,  the  first  stage  in  which  the  sender 
is  either  in  the  slow  start  or  the  congestion  avoidance  phase.  The  fast  recovery  mechanism  which 
constitutes  the  second  stage  follows  the  detection  of  a  packet  loss.  During  this  stage  the  window 
size  is  reduced  and  the  packets  inferred  to  be  lost  are  retransmitted.  The  third  stage  consists  of 
the  retransmit  timeout  interval.  While  the  first  stage  is  present  in  every  cycle,  the  second  and 
the  third  stages  may  or  may  not  be  present  depending  on  the  packet  loss(es).  Note  that  with  our 
assumptions  only  one  of  either  the  second  or  the  third  stages  is  present  in  a  NewReno  sender. 

In  order  to  explain  the  working  of  these  algorithms  we  define  ki\i  minicycle  of  the  first  stage 
of  fth  cycle  to  be  the  time  taken  to  transfer  the  kt\i  window  of  packets  during  the  first  stage  of 
the  fth  cycle.  Hence,  the  first  minicycle  corresponds  to  the  first  window  of  packets  on  the  start 
of  a  new  cycle.  Thus,  every  cycle  of  NewReno  if  in  slow  start  phase  begins  with  one  packet  being 
transmitted  in  the  first  mini-cycle  and  if  it  is  in  the  congestion  avoidance  phase,  then  the  number 
of  packets  transmitted  in  the  first  mini-cycle  depends  on  the  window  size  when  the  packet  drop  was 
detected  in  the  previous  cycle.  In  every  successive  mini-cycle  the  number  of  packets  transferred  is 
double  the  number  of  packets  transferred  during  the  present  mini-cycle  as  long  as  the  sender  is  in 
the  slow  start  phase.  During  the  congestion  avoidance  phase  the  number  of  packets  transferred  in 
each  mini-cycle  is  one  more  than  the  number  of  packets  transferred  during  the  previous  mini-cycle.^ 
This  goes  on  until  there  are  one  or  more  packet  drops  in  a  particular  cycle  causing  the  ack  cycle  to 
either  dry  up  or  generate  enough  duplicate  acks  resulting  in  the  end  of  the  first  stage  of  the  cycle. 
End  of  the  first  stage  can  lead  to  the  second  stage.  Since  a  NewReno  sender  recovers  only  one  lost 
packet  per  rtt  during  the  fast  recovery  stage,  we  consider  that  each  minicycle  during  the  second 
stage  carries  a  single  packet  which  is  being  retransmitted.  In  practice,  there  may  also  be  some  new 
packets  transmitted  during  this  phase.  We  do  not  take  these  new  packets  into  consideration.  On 
the  other  hand  practical  implementations  have  a  bound  on  the  number  of  packets  which  can  be 
transmitted  once  the  fast  recovery  stage  is  finished.  We  do  not  consider  such  bounds  and  hence 

^For  ease  of  explanation,  we  are  ignoring  some  constraints  like  delayed  acks,  which  though  can  be  easily  incorpo¬ 
rated  into  the  description 
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both  these  effects  should  cancel  out  each  other  in  our  analysis  thereby  having  the  analytical  model 
follow  the  practical  TCP  implementations  closely. 

We  assume  that  all  the  packets  in  a  mini-cycle  travel  in  what  we  call  a  train.  Thus,  there  is 
a  packet  train  in  every  mini-cycle  and  the  size  of  the  packet  train  in  the  ki\i  mini-cycle  k  >  1, 
depends  on  the  size  of  the  packet  train  in  the  previous  mini-cycle  and  the  phase  of  the  NewReno 
sender.  A  new  packet  train  starts  once  the  ack  for  the  first  successful  packet  of  the  previous  packet 
train  comes  back.  This  train  ends  when  the  packets  corresponding  to  the  last  ack  of  the  previous 
train  have  been  transmitted  by  the  sender  or  a  certain  number  of  duplicate  acks  reach  the  sender 
thus  giving  some  length  to  the  train.  Start  of  a  successful  timeout  at  any  point  also  terminates  a 
train.  The  length  of  the  packet  train  which  is  the  distance  between  the  first  packet  of  the  train 
and  the  last  packet  of  the  train  keeps  on  increasing  since  the  number  of  packets  in  successive  trains 
is  an  increasing  function.  A  great  convenience  offered  by  the  packet  train  concept  is  that  it  helps 
to  differentiate  packets  on  the  basis  of  the  mini-cycle  that  they  belong  to.  This  as  we  see  later 
greatly  helps  in  calculating  the  throughput  of  a  flow.  This  is  because  once  we  know  the  number 
of  trains  in  a  cycle  as  well  as  the  window  size  cr  when  the  packet  drop  was  detected  in  the  last 
cycle,  the  expected  number  of  packets  in  the  cycle  as  well  as  the  mean  cycle  duration  can  be  easily 
calculated.  As  we  see  later,  this  is  the  approach  that  we  take  to  characterize  the  throughput  of  a 
flow.  Of  course,  the  expected  number  of  trains  in  a  cycle  as  well  as  the  mean  loss  window  depend  on 
the  TCP  algorithm  followed  as  well  as  on  the  packet  loss  probability  characteristics  of  the  wireless 
channel. 

Example:  Before  proceeding  further,  we  illustrate  the  above  concepts  using  an  example  of  a 
TCP  NewReno  sender.  Consider  the  evolution  of  a  TCP  NewReno  sender  as  shown  in  table  4a. 
We  start  observation  when  the  ack  for  packet  14  reaches  the  sender.  We  assume  that  packets  15-18 
is  lost.  Thus  the  first  stage  of  this  cycle  ends  on  account  of  the  fast  retransmit  feature  when  the 
third  duplicate  ack  reaches  the  sender  since  the  receiver  has  received  packet  21.  The  second  stage 
starts  with  the  transmission  of  packet  15.  On  the  receipt  of  the  ack  for  packet  15,  the  next  packet 
16  is  retransmitted.  This  repeats  until  packet  18  is  retransmitted.  Thus  all  the  lost  packets  are 
recovered  by  retransmitting  only  one  lost  packet  per  rtt.  This  cycle  ends  once  the  ack  for  packet 
18  comes  back,  following  which  a  new  cycle  begins. 

Since  the  previous  cycle  did  not  have  the  third  stage,  the  sender  starts  in  the  congestion  avoid¬ 
ance  phase  in  the  first  stage  of  the  new  cycle.  Packets  23-26  are  transmitted  on  the  start  of  the 
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new  cycle  and  these  packets  constitute  the  first  train.  A  new  train  (second  train)  starts  once  the 
ack  for  packet  23  reaches  the  sender  and  ends  when  the  packets  corresponding  to  the  last  ack  of 
the  previous  train  (for  packet  26)  have  been  transmitted.  Thus  the  second  train  starts  with  packet 
27  and  ends  with  packet  31.  We  assume  that  the  first  packet  dropped  in  this  cycle  is  in  the  second 
train  which  is  packet  29.  Packets  30  and  31  are  also  assumed  to  be  lost. 


Pkt  Reed  info  in  ack 

Ack  for  pkt 

U) 

W 

Pkt  sent 

14 

14 

5  (say) 

8 

22 

14  I  dup  ack 

19 

5 

8 

(pkt  15-18  lost) 

14  II  dup  ack 

20 

5 

8 

- 

14  III  dup  ack(II  stage) 

21 

4 

7 

15 

14  IV  dup  ack 

22 

4 

8 

15 

15 

4 

4 

16 

16 

16 

4 

4 

17 

17 

17 

4 

4 

18 

22 (New  cycle,  I  train) 

18 

4 

4 

23,24,25,26 

23(11  train) 

23 

4 

4.. 

27 

24 

24 

4 

4.. 

28 

25 

25 

4 

4.. 

29(lost) 

26 

26 

4 

5 

30  (lost), 31  (lost) 

27(111  train) 

27 

4 

5.. 

32 

28 

28 

4 

5.. 

33 

Timeout  (III  Stage) 

28(1  dup  ack) 

32 

4 

5... 

- 

28(11  dup  ack) 

33 

4 

5.. 

- 

New  cycle 

- 

2 

1 

29 

Table  4a:  A  TCP  NewReno  cycle 


Since  packet  27  is  successful,  the  third  train  starts  on  the  receipt  of  the  ack  for  packet  27  with 
the  transmission  of  packet  32.  Note  that  the  TCP  sender  has  not  yet  detected  the  loss  of  packet  29. 
Packet  33  is  sent  on  the  receipt  of  the  ack  for  packet  28.  Since  the  next  three  packets  (29-31)  are 
lost  no  acks  arrive  for  those  packets.  This  signifies  the  end  of  the  first  stage  of  this  cycle.  At  the 
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same  time  the  timeout  clock  starts  ticking  after  the  transmission  of  packet  33.  The  acks  for  packet 
32  and  packet  33  are  duplicate  acks  and  hence  do  not  result  in  the  transmission  of  any  packets. 
Note  that  if  not  for  the  packet  losses,  then  a  new  train  starts  with  the  receipt  of  the  ack  for  packet 
32.  Because  of  the  lack  of  enough  duplicate  acks  this  cycle  ends  with  the  third  stage  of  a  timeout. 
In  this  cycle  we  have  two  stages  the  first  stage  and  the  third  stage.  The  next  cycle  starts  with  the 
retransmission  of  packet  29  and  the  process  continues.  Note  that  since  the  last  cycle  ended  with  a 
timeout,  hence  the  sender  in  the  new  cycle  begins  in  the  slow  start  phase  while  in  the  first  stage. 

Now  consider  the  other  TCP  algorithms.  Any  TCP  sender,  whether  OldTahoe,  Tahoe  or  Sack 
when  sending  new  data  is  generally  either  in  the  slow  start  phase  or  the  congestion  avoidance  phase. 
An  OldTahoe  sender  uses  timeout  as  the  mechanism  to  infer  packet  losses.  A  Tahoe  sender  on  the 
other  hand  can  also  use  the  fast  retransmit  mechanism.  Both  these  senders,  resort  to  slow-start 
after  the  detection  of  a  packet  loss  by  reducing  the  window  size  to  one.  The  Sack  sender  on  the 
other  hand  uses  the  fast  retransmit  mechanism  to  infer  packet  losses.  But  following  the  detection 
of  a  packet  loss  the  Sack  sender  like  the  NewReno  sender  resorts  to  the  fast  recovery  mechanism 
whereby  the  window  size  is  reduced  to  half  and  the  sender  uses  additional  incoming  acks  to  clock 
outgoing  packets.  The  fast  recovery  mechanism  concludes  successfully  when  all  the  lost  packets  have 
been  recovered  and  this  is  followed  by  the  congestion  avoidance  mechanism.  Of  course,  if  there  are 
not  enough  duplicate  acks  as  required  by  the  fast  retransmit  mechanism  then  a  retransmit  timeout 
has  to  be  resorted  to,  following  which  the  sender  always  starts  in  the  slow  start  phase. 

Thus,  a  cycle  of  a  Tahoe  or  OldTahoe  sender  starts  with  the  slow  start  phase  and  ends  following 
the  detection  of  a  packet  loss  either  on  the  basis  of  the  ack  based  fast  retransmit  mechanism  or  the 
timer  based  retransmit  timeout  mechanism.  On  the  other  hand  a  cycle  of  the  Sack  sender  begins 
with  either  the  slow  start  phase  or  the  congestion  avoidance  phase  following  the  detection  of  a 
packet  loss.  The  cycle  ends  either  with  the  successful  conclusion  of  the  fast  recovery  mechanism  or 
on  the  basis  of  the  retransmit  timeout  mechanism.  Thus  the  OldTahoe,  Tahoe  and  Sack  senders 
always  have  the  first  stage  in  a  cycle.  An  OldTahoe  sender  does  not  have  the  second  stage  of  fast 
recovery  and  always  has  the  third  stage  of  retransmit  timeout.  The  Tahoe  sender  will  not  have 
the  second  stage  and  may  or  may  not  have  the  third  stage  of  a  timeout  depending  on  whether 
enough  packets  are  successful  after  the  lost  packet  for  the  fast  retransmit  mechanism  to  succeed.  In 
contrast  a  Sack  sender  like  the  NewReno  sender  can  have  either  the  second  stage  of  fast  recovery  or 
the  third  stage  of  a  retransmit  timeout  if  adequate  acks  to  activate  the  fast  retransmit  mechanism 
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are  not  present. 

We  now  go  back  to  the  analysis.  Let  the  number  of  trains  in  a  cycle  be  denoted  by  n.  On  the 
basis  of  our  explanation  above  it  is  clear  that  there  are  two  types  of  trains,  type  1  trains  during 
Stage  1  and  type  2  trains  during  Stage  2.  The  first  type  of  trains  are  the  normal  trains  constituting 
the  first  stage  of  a  cycle.  Let  ni  denote  the  number  of  such  trains.  The  type  2  trains  are  those 
constituting  Fast  Recovery.  In  case  of  NewReno  these  trains  have  only  one  packet  such  that  the 
particular  packet  has  been  detected  to  be  lost  previously.  Let  n2  denote  the  number  of  such  trains. 
Note  also  that  n2  =  0  for  Tahoe  and  OldTahoe.  n2  =  1  for  Sack  if  the  cycle  does  not  end  in 
a  timeout.  This  is  because  Tahoe  and  OldTahoe  do  not  have  fast  recovery  while  Sack  has  fast 
recovery  but  it  does  not  have  many  of  these  trains  since  it  is  not  constrained  to  retransmit  at  most 
one  dropped  packet  per  round  trip  time  as  in  case  of  Reno  or  NewReno. 

As  is  clear  from  the  above  explanation  every  cycle  of  OldTahoe  and  Tahoe  starts  with  a  slow 
start.  In  case  of  NewReno  and  Sack,  a  cycle  begins  in  the  slow  start  phase  only  after  a  timeout 
has  occurred.  In  the  sequel  the  size  of  the  kt\i  type  1  train  in  case  of  such  cycles  is  denoted  by  6k- 
Thus,  6k  denotes  the  number  of  packets  in  the  kt\i  train.  Further,  6k  =  f{6k-i)  and  thus  depends 
on  the  TCP  algorithm  followed.  We  also  let  6o  =  0.  For  the  cycles  of  NewReno  and  Sack  starting 
in  the  congestion  avoidance  phase,  the  size  of  the  kt\i  type  1  train  is  denoted  by  6k- 

The  size  of  the  loss  window  i.e.  the  window  size  at  which  the  packet  loss  is  detected  by  the 
sender  is  denoted  by  a-  Wm  denotes  the  maximum  size  that  the  window  can  grow  to,  which  by 
our  earlier  assumptions  is  given  by  Wm  =  k-T  +  1,  where  jj,  denotes  the  bandwidth  of  the  wireless 
link  while  the  round  trip  time  (rtt)  of  the  link  is  denoted  by  T.  Further  denotes  the  steady 
state  probability  of  a  timeout  in  a  cycle.  We  would  like  to  remark  that  we  will  introduce  further 
notation  as  we  go  along  when  necessary. 

With  this  let  us  consider  the  packet  trains.  The  metric  that  we  consider  to  evaluate  the  different 
TCP  algorithms  is  the  throughput  which  we  define  next.  Let  the  number  of  packets  transferred 
during  a  cycle  be  denoted  by  Q  while  the  duration  of  the  cycle  be  denoted  by  Q-  Note  that  both 
Q  and  C,  are  random  variables.  The  steady  state  throughput  A  obtained  by  the  TCP  connection  is 
given  as 


A  = 


E{Q) 

EiO 


(3) 


To  determine  the  number  of  packets  sent  in  a  cycle,  we  need  to  know  not  only  the  number  of  trains 


16 


in  the  cycle  but  also  the  window  size  in  the  previous  cycle  at  which  a  packet  loss  was  detected. 
Also  let  Q  denote  the  number  of  packets  sent  before  the  first  dropped  packet.  Q  denotes  the  sum 
of  Q  and  the  number  of  packets  in  the  second  stage  if  present,  e  denotes  the  number  of  packets 
successfully  sent  by  the  source  after  the  packet  loss  but  before  the  packet  loss  is  detected  by  the 
sender  while  still  in  the  first  stage.  Hence,  we  have 

E{Q)  =  E[E{Q/ni,n2,(j)]  +  E{e) 

=  EEE  P{ni,n2,  a)E{Qlni,n2,  a)  +  E{a) 

a  m  712 

=  E  E  E  P{n2/ni,a)E{Q/ni,n2,  a) 

a  m  7i2 

+E{a) 

=  ^  P{a)  ^  P(ni/cr)  ^  P{n2/ni,a)  [n2  +  E{Q/ni,a)] 

a  ni  712 

+E(a) 

=  E[E{n2/nu  a)]  +  E[E{Q/ni,(j)]  +  E{a)  (4) 

Til 

E{Qlni,a)  =  ^ek  (5) 

A:=0 

The  fourth  equation  above  follows  from  the  third  equation  since  E{Q Ini,n2,  cr)  =  712  +  E{Qlni,  a). 
For  the  derivation  above  for  simplicity  we  assume  that  E{e)  =  E{a). 

Remark:  In  the  above  P{a)  denotes  the  steady  state  probability  of  the  loss  window,  i.e.  the 
window  size  in  the  cycle  at  which  the  first  stage  ends  due  to  a  packet  loss  which  is  also  the  same 
as  the  window  size  at  which  the  packet  loss  is  detected  by  the  sender.  P(ni/cr)  denotes  the  steady 
state  conditional  probability  on  the  number  of  type  1  trains  given  the  loss  window  while  P(n2/ni,  a) 
is  the  steady  state  conditional  probability  on  the  number  of  type  2  trains  given  the  loss  window 
and  the  number  of  type  1  trains.  E{Qfni,  a)  denotes  the  expected  number  of  packets  in  stage  1  of 
a  cycle  given  the  loss  window  and  the  number  of  trains  in  the  first  stage. 

We  next  look  at  the  expected  cycle  time.  Let  (pk  denote  the  round  trip  time  taken  by  a  packet 
of  the  kt\i  type  1  train.  Then  we  have 


Cot 

ni  +  l 

=  4>k  +  n 

(6) 

k=l 

ni  +  1 

Ct 

~  ^  ^  (pk  T  ItP 

k=l 

(7) 
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Figure  1:  Gap  between  different  trains 


(nr 

m+i 

=  ^2  4>k  +  {^  —  Fr)n2T'  +  ItR 

(8) 

k=l 

m+i 

Cs 

=  ^2  4>k  +  —  It)T  +  IrTt 

(9) 

k=l 


where  denotes  the  indicator  function  of  the  timeout  event  and  Tt  denotes  the  value  of  the  timeout 
interval  which  is  typically  a  multiple  of  500ms.  OT  refers  to  OldTahoe,  T  refers  to  Tahoe,  NR 
to  NewReno  and  S  to  Sack.  We  would  also  like  to  point  out  that  the  summation  in  the  above 
equations  is  over  ni  +  1  type  1  trains  since  a  packet  lost  in  the  nith  type  1  train  can  be  detected  by 
the  sender  only  in  the  ni  +  1th  type  1  train  as  also  seen  in  case  of  the  example  given  earlier.  Further, 
effect  of  the  exponential  backoff  in  case  of  multiple  timeouts  can  be  incorporated  by  substituting 
a  random  variable  denoting  the  size  of  the  timeout  interval  instead  of  It-ti  in  the  equations  above. 
Taking  expectations,  assuming  E{(f)k)  =  T  we  have 


E{Cot) 

=  {E{ni)  +  1)T  +  Tt 

(10) 

P(Ct) 

=  (E(ni)  +  1)  T  +  TfEr 

E{Cnr) 

=  (E(ni)  +  l)T  +  E(n2)T  +  TtPr 

EiCs) 

=  (E(ni)  +  1)  T  +  (1  —  Pr)T  +  TfEr 

At  this  point,  we  can  use  equations  4  and  10  in  equation  3  in  order  to  calculate  the  throughput 
of  a  TCP  flow  for  any  of  the  TCP  senders  namely  OldTahoe,  Tahoe,  NewReno  or  Sack.  But  in  order 
to  use  equations  4  and  10  for  any  TCP  versions,  we  need  to  specify  expressions  for  P(cr),  P(ni/cr) 
and  P(n2/ni,  cr),  E{Qfni,a)  and  P^-  Hence,  we  next  try  to  evaluate  the  expressions  P(cr),  P(ni /cr) 
and  P(n2/ni,  cr),  P(Q/ni,  cr)  and  P^  calling  them  as  the  loss  window  probability  calculation,  train 
probability  calculation,  packet  count  calculation  and  timeout  probability  calculation  respectively  for 
the  different  TCP  algorithms.  We  would  like  to  point  out  that  due  to  the  different  mechanics  of  the 
various  TCP  algorithms,  the  required  expressions  above  would  highly  depend  on  the  TCP  algorithm 
being  considered.  We  remark  here  that  this  entire  approach  to  characterize  the  throughput  of  a 
window  based  protocol  is  what  we  call  the  packet  train  model. 
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Since,  we  are  considering  the  packet  train  model,  the  success  or  failure  of  a  particular  packet 
depends  on  the  success  or  failure  of  the  previous  packet  as  long  as  both  the  packets  are  in  the 
same  train.  As  far  as  the  first  packet  of  a  train  is  concerned,  in  the  sequel  we  assume  that  the  first 
packet  of  every  train  finds  the  wireless  link  in  its  steady  state.  In  other  words,  the  first  packet  of 
every  train  finds  the  wireless  link  in  the  good  state  with  probability  ttg  and  in  the  bad  state  with 
a  probability  -kb-  This  implies  that,  as  shown  in  figure  1,  effect  of  the  success  or  failure  of  packet 
A  on  packet  B  is  negligible.  This  is  realistic  as  long  as  the  intertrain  gap  is  large  enough  which 
happens  when  we  consider  large  bandwidth  links  under  scenarios  whereby  the  window  does  not 
grow  to  the  maximum  possible  values.  In  such  a  case  the  duration  between  trains  is  quite  large 
compared  to  the  packet  transmission  time  and  hence  our  assumption  does  in  fact  reflect  reality. 
Another  reason  for  making  this  assumption  is  also  that  the  mean  intertrain  gap  in  case  of  the 
different  TCP  algorithms  is  also  large  enough.  Finally  this  assumption  is  also  justified  due  to  the 
fact  that  we  are  interested  in  the  comparison  of  different  TCP  algorithms  operating  over  a  wireless 
link  and  hence  this  assumption  affects  all  the  different  algorithms  to  the  same  extent. 

Scenarios  whereby  the  window  does  grow  to  the  maximum  possible  values  such  that  the  in¬ 
tertrain  gap  in  figure  1  is  low  enough  can  also  be  very  easily  taken  care  of.  This  can  be  done  by 
calculating  the  window  size  W  until  which  our  assumption  holds.  This  window  size  VF  is  a  function 
of  the  intertrain  gap  which  depends  on  the  bandwidth  of  the  link  and  the  packet  size.  For  window 
sizes  beyond  W,  we  consider  that  the  success  or  failure  of  the  first  packet  of  a  train  depends  on  the 
success  or  failure  of  the  last  packet  of  the  previous  train  while  for  window  size  less  than  W  we  use 
the  same  approach  as  above.  We  do  not  further  pursue  this  approach  for  simplicity. 

5  Throughput  Characterization 

In  this  section  we  proceed  to  specify  expressions  for  the  loss  window  probability  calculation,  train 
probability  calculation,  packet  count  calculation  and  timeout  probability  calculation.  We  do  this 
only  for  TCP  Tahoe  for  lack  of  space.  Expressions  for  the  other  algorithms  follow  similarly  as  the 
expressions  for  Tahoe  and  are  provided  in  detail  in  [1]. 
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5.1  Loss  Window  Probability  Calculation 

We  next  describe  the  approach  that  we  take  in  order  to  calculate  -P(cr).  Let  Wp  denote  the  maximum 
window  size  reached  in  the  pth  cycle.  Thus  {Wp}p  denotes  the  sequence  of  window  sizes  at  which 
packets  are  dropped  in  successive  cycles.  It  is  obvious  that  the  loss  window  sequence  {Wp}p  forms 
a  Markov  chain.  Hence,  in  order  to  determine  the  steady  state  probability  of  the  loss  window 
P(cr),  cr  =  1,  2,  •  •  • ,  Wm  we  seek  to  characterize  the  probability  P(kFp_|_i  =  ijfWp  =  a).  Given  the 
transition  probability  matrix,  we  can  generate  the  stationary  distribution  P{a)  using  any  of  the 
standard  methods.  Thus  during  the  window  probability  calculation  we  characterize  the  transition 
probability  matrix  P(kFp_|_i  =  ijlWp  =  a). 

Proposition  1  Transition  Probability —  Consider  TCP  OldTahoe  or  TCP  Tahoe.  Let  the 
wireless  link  be  governed  by  the  correlated  loss  model  with  parameters  a  and  jS.  Then,  with  u)  as 
the  slow  start  threshold  we  have, 

a(l  —  (no  +  —oj  <  k  <  0&  log2{uJ  +  k)  not  int 

(1  —  (no  +  ■  —oj  <  k  <  0&  log2{uJ  +  k)  int 

(ttgQ!  +  7rB(l  -  (5)) 

P{Wp  =  u  +  k/Wp.i  =  a)  =  \  (11) 

(1  -  a)^3  t)<k<Wm-u^ 

(1  -  V’l  - 

where 

71  =  \log2{oj  +  k)] 

72  =  \log2{u)y\  +  k 

73  =  s{u)  —  l,k)  =  u)  —  1  +  u)  +  ■  ■  ■  +  u)  —  1  +  k 

ri  =  7rG(l-<+'= 

=  7rB/3(l-<+^-i 

Proof:  Consider  a  TCP  Tahoe  cycle.  Every  cycle  starts  with  a  window  of  one  and  a  slow  start 
threshold  of  w.  Then  during  the  slow  start  phase,  the  window  advances  by  one  for  every  successful 
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packet.  Hence,  to  achieve  a  window  of  77,  77  <  w,  77  —  1  packets  have  to  be  successful.  Let  Ss{r]) 
denote  the  probability  of  packets  successfully  reaching  the  receiver  so  as  to  attain  a  window  size  of 
77  such  that  77  belongs  to  the  slow  start  phase  and  Fg  (77)  denote  the  probability  of  a  packet  loss  so 
as  to  have  a  loss  window  size  of  77,  such  that  77  belongs  to  the  slow  start  phase.  Thus,  during  the 
slow  start  phase  the  probability  of  having  a  loss  window  of  77  in  the  pth  cycle  given  that  the  loss 
window  during  the  previous  cycle  is  a  is  given  by  S's  (77)^5  (77).  We  need  to  show  that 


Ssiv)  =  (!-«)''  ^  TTG  +  Tj-^ 

1  —  a_ 


Ro52(»7)1 


Fs{ri) 


■Kca  +  'kb{^  —  /3)  log2{ri)\s  an  integer 
a  log2{r])is  not  an  integer 


uj  +  k  is  the  drop  window  size  during  the  cycle  of  interest.  Since  we  consider  TCP  Tahoe  during 
the  slow  start  phase,  we  have  k  <  0.  Now,  the  window  size  and  the  slow  start  phase  together  imply 
that  uj  +  k  —  1  packets  have  been  successful  while  the  uj  +  kt\i  packet  has  been  dropped.  The  train 
number  corresponding  to  packet  u)  +  k  —  l  is  \log2{oo  +  k)~\ .  Let  log2{uj  +  k)  not  be  an  integer  which 
implies  that  the  uj  +  kt\i  packet  is  not  the  first  packet  of  any  train.  In  such  a  case,  the  probability  of 
dropping  the  uj  +  kt\i  packet  is  affected  by  what  happened  to  packet  uj  +  k  —  1.  But  packet  uj  +  k  —  1 
has  been  successful.  Hence 


Fs{uj  +  k)  =  a  if  +  ^)  is  not  an  integer  (12) 

Now  consider  that  log2{uj  +  k)  is  an  integer.  In  such  a  case  the  uj  +  kt\i  packet  is  the  first  packet 
of  a  train.  Hence,  it  is  not  affected  by  what  happened  to  the  previous  packet.  The  probability  of 
dropping  the  uj  +  kt\i  packet  is  then  given  by 

Fg  [uj  +  k)  =  ^  Prob  that  channel  is  in  ith  state  .  probability  of  dropping  packet 

i=good,bad 

=  ttgo;  +  7rB(l  — /3)  if  +  ^)  is  an  integer  (13) 

Now  consider  the  probability  oi  uj  +  k  —  1  packets  being  successful,  uj  +  k  —  1  packets  occupy 
\log2{uj  +  k)~\  trains.  The  channel  is  in  a  good  state  before  the  start  of  a  new  train  with  probability 
■KG-  Hence,  the  first  packet  of  the  train  in  such  a  condition  is  successful  with  probability  1  —  a. 
While  if  the  channel  is  in  a  bad  state  before  the  start  of  a  train,  which  happens  with  probability 
■Kb,  then  the  packet  is  successful  with  a  probability  /3.  Thus,  note  that  we  have  \log2{uj  +  k)~\  places 
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to  fill  with  either  -kq  or  -kb  in  all  possible  combinations.  Hence,  we  have 


Ssil)  = 


TT, 


gog2(a;+/c)l-i^j  -  +  •  •  •  +  (1  -  a)“+^-l-r*°S2(a;+/c)l  Ro92(a;+/c)l 


=  (l-a)“+^-^ 
=  {l-aY+'^-^ 


\log2(uj+k)'\  ( 


E 

i=0 

ttg  + 


|"/og2(w  +  A:)]  I  |-;og2(w+A:)l-i 


TT, 


G 


V 

TTfi/? 


7rB/3(l 


—  a 


,-i 


1  —  a 


[log2(oj+k)'j 


(14) 


Thus  the  expression  for  the  transition  probability  for  the  case  k  <  0  i.e.  the  slow  start  phase, 
follows  from  equations  12,  13  and  14. 

Now  consider  the  case  A:  >  0  i.e.  the  congestion  avoidance  phase.  Let  S'g  (77)  denote  the 
probability  of  packets  successfully  reaching  the  receiver  so  as  to  attain  a  window  size  of  ij  such  that 
r]  belongs  to  the  congestion  avoidance  phase.  Further,  let  F^r])  denote  the  probability  of  a  packet 
loss  so  as  to  have  a  loss  window  size  of  77,  such  that  77  belongs  to  the  congestion  avoidance  phase. 
Thus,  during  the  congestion  avoidance  phase  the  probability  of  having  a  loss  window  of  77  in  the 
pth  cycle  given  that  the  loss  window  during  the  previous  cycle  is  a  is  given  by  {r])Fc{'r])-  In  this 
case  we  need  to  show  that 


S^civ) 

FM 


(1  - 

1  “  ~  ~ 
1  r]  =  Wm 


ttg  + 


TTfi/? 


llog2{uj)]+r)-uj 


1  —  a_ 

-kb(3{1  -  r]  <Wrr 


During  the  congestion  avoidance  phase,  the  window  advances  by  one  packet  for  every  successful 
window  of  packets  delivered.  Further,  for  a  drop  window  oi  uj  +  k  during  the  present  cycle  at  least 
one  of  the  uj  +  k  packets  has  to  be  unsuccessful.  Probability  that  not  a  single  packet  of  a  train  with 
size  uj  +  k  is  dropped  is  given  by  7rG'(l  —  0;)“"’“^  +  ttbPY  ~  Hence,  we  have 

Fcico  +  k)  =  1  -  noil  -  -  TTBPil  -  uj  +  k<Wm  (15) 

while  a  uj  +  k  =  Wm,  then  Fc(a;  +  k)  =  1  since  a  packet  is  surely  dropped. 

Further,  the  congestion  avoidance  phase  starts  after  u>  —  l  packets  are  successful.  Hence  to  reach 
a  window  of  u>  +  k  k  >  0,  we  require  s(u>  —  1,  k)  =  u)  —  l  +  u)  +  u)  +  l  +  --  -+  u)  +  k  —  1  successful 
packets.  These  s(a;  —  l,k)  packets  occupy  \log2{ooy\  +k  trains.  Hence,  we  have  using  an  approach 
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similar  to  equation  14 


S'^^{u  +  k)  =  (1 


ttg  + 


1  —  a 


\log2(uf)\+k 


(16) 


Thus  the  expression  for  the  transition  probability  for  the  case  k  i.e.  the  congestion  avoidance 
phase,  follows  from  equations  15  and  16. 

o 

Remark:  Note  that  by  letting  /3  =  1  —  a  we  obtain  an  iid  packet  loss  model.  The  transition 
probability  for  such  a  case  with  p  =  a  is  given  as 


P{Wp  =  u  +  k/Wp.i  =a)  =  { 


F  — w  <  A:  <  0 

(1  -  p)*(‘^-h^)  [l  -  (1  -  p)“+^]  0  <  A:  <  Vk™  -  w 


5.2  Timeout  Probability  Calculation 


For  the  timeout  probability  calculation  we  have 

Pr  =  (17) 

cr'  =  l 

where  is  the  probability  of  timeout  in  a  cycle  given  that  the  loss  window  is  o' .  Hence,  we  next 
proceed  to  specify  the  expression  for  . 

We  would  like  to  remark  here  that  the  starting  point  for  the  channel  is  the  bad  state.  But  we 
calculate  the  timeout  probability  assuming  that  all  the  packets  in  the  loss  window  belong  to  the 
same  train.  Note  that  this  is  an  approximation  in  the  case  whereby  a  packet  is  lost  from  the  middle 
of  a  train  in  which  case  the  entire  loss  window  consists  of  packets  from  two  different  trains.  For 
such  a  case,  we  also  have  to  consider  the  channel  state  that  the  first  packet  of  the  second  train 
encounters.  This  could  be  taken  care  of  at  the  cost  of  extra  complexity  but  we  choose  not  to  do 
so.  Further,  since  this  assumption  is  done  for  all  the  TCP  algorithms  it  does  not  affect  the  results. 


Proposition  2  Timeout  Probability:  Consider  TCP  Tahoe  during  the  pth  cycle.  Let  >  0 
denote  the  number  of  duplicate  acks  on  the  receipt  of  which  the  sender  enters  the  fast  retransmit 
phase.  Then  Tq-',  the  probability  of  timeout  given  that  the  loss  window  is  o'  is  given  by 


a' —  2  min{a' —  l—i,i+l)  min{m,i) 

=  E  E  E 

i=a' —  Q,  m=l  l=m—l 

\a'-l 


(  >  ■  0  \ 

/  •  \ 

o  —  t  —  2 

y  cr'  —  1— f— m  ^ 

+  (1-/3)^ 


{I- 

(18) 
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Proof:  A  timeout  results  if  and  only  if  less  than  Q  duplicate  acks  arrive  at  the  sender.  In  a 
loss  window  of  a',  one  packet  is  already  lost.  Hence,  a  timeout  occurs  if  and  only  if  the  number  of 
packets  lost  after  the  first  packet  loss  is  greater  than  or  equal  to  a'  —  If.  Note  that  the  maximum 
number  of  packets  which  can  be  lost  at  this  point  is  cr  =  cr'  —  1  since  a  packet  is  already  lost  in  a 
window  of  a' . 

Hence,  with  this  let  us  consider  the  case  of  i  drops.  We  remark  here  that  a  timeout  results  if 
and  only  if  *  >  cr'  —  If.  Note  that  if  *  =  cr'  —  1  then  probability  of  timeout  is  given  by  (1  —  (3^ . 
Hence,  we  next  consider  cr'  —  1  >  *.  These  i  drops  are  possible  either  by  having  the  channel  in  a  bad 
state  at  the  beginning  of  a  transmission  and  transitioning  to  the  bad  state  itself,  which  happens 
with  probability  1  —  /3  or  by  having  the  channel  in  a  good  state  at  the  beginning  of  a  transmission 
and  transitioning  to  a  bad  state  which  happens  with  probability  a.  Let  I  indicate  the  number  of 
times  that  the  channel  starts  in  a  good  state.  Hence,  we  have  the  probability  of  i  drops  as 

(19) 

i  packet  drops  also  imply  that  the  rest  of  the  packets  are  not  dropped  and  result  in  duplicate  acks. 
Again  two  scenarios  result  here  with  the  channel  beginning  in  a  good  state  or  a  bad  state.  Let  m 
denote  the  number  of  times  that  the  channel  starts  in  the  bad  state.  Hence,  the  probability  of  i 
drops  implies  that  a  —  i  packets  get  through  which  is  given  by  the  probability 

/3™(1 -a)-"-*-™  (20) 

The  probability  of  one  such  way  of  a  timeout  occurring  is  (1  —  /3)*“*q;* /?"*(!  —  0;)'^“*“"*.  +  +  (3  * 
*a  +  +/3  *  *a  ■  ■  ■  *  *a  denotes  the  general  form  of  a  trace  of  packet  successes  or  losses  leading  to 
a  timeout  with  1  —  /3  raised  to  appropriate  power  occupying  the  ++  spaces  and  1  —  a  raised  to 
appropriate  power  occupying  the  **  spaces.  Note  that  a  (3  cannot  occur  after  a  (3  unless  an  a  has 
occurred  between  them  and  vice  versa.  Hence,  we  have  l  =  m  01  l  =  m  —  1  i.e. 

m  >  I  >  m  —  1 

Further, 


(7  —  i  —  m  >  0  - 

■>  a  —  i  >  m 

(21) 

1 

IV 

0 

1 

■>  i  >  1 

(22) 

- 

■>  *  +  1  >  m  >  / 

(23) 
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Thus,  given  i,  I  and  m  we  next  look  at  the  number  of  possible  combinations  of  a  trace  leading 
to  a  timeout.  Consider  the  pair  (3  and  1  —  a.  Note  that  since  we  are  starting  with  a  lost  packet,  the 
pattern  (1  —  a)-^  /  =  0, 1,  2,  •  •  •  can  occur  only  after  /3  has  occurred.  Thus,  /3  occurs  m  times,  while 
the  pattern  1  —  a  can  occur  a  —  i  —  m  times  such  that  (3  precedes  the  trace.  Hence,  m  —  1  /3’s  each 
raised  to  power  1,  can  appear  in  any  order  with  a  —  i  —  m  repetitions  of  1  —  a  with  no  restrictions 
on  consecutive  appearances  of  1  —  a.  Thus,  we  are  asking  for  the  number  of  subpopulations  of  size 
cr  —  *  —  m  in  a  population  of  size  a  —  i— m  +  m  —  1  which  equals 


/ 


(24) 


V 


a  —  i  —  1 
a  —  i  —  m 

Similarly,  considering  the  pattern  of  a  and  1  —  /3,  we  are  asking  for  the  number  of  subpopulations 
of  size  *  —  /  in  a  subpopulation  of  size  i  —  I  +  I  which  equals 


i 

i-l 


(25) 


) 


since  the  first  occurrence  of  a  can  be  after  1— /3  has  occurred.  Thus  the  total  number  of  combinations 
is  given  by  the  product  of  equations  24  and  25.  Hence,  probability  of  a  timeout  given  i  losses  r^/, 
such  that  cr  >  *  >  cr'  —  is  given  by 


T„/ 


min{a—i,i+l)  min(m,i) 

CF  —  i  —  1 

(  i  \ 

E  E 

m=l  l=m-l 

^  a  —  i  —  m  ^ 

+  j 

[I  -  (3y-^a^ (3'^{l  - 


Thus,  the  probability  of  a  timeout  given  a  loss  window  size  of  cr'  then  follows  as 

fj—\  min(a—i,i+l)  min(m,i)  / 

=  E  E  E 

i=a' —Q.  m=l  l=m—l  ^ 

+(1-/3)" 


a  —  i  —  1 


o  —  i  —  m 


{l-f3Y-^a^f3'^{l-ay 


i-l 


o 

It  is  to  be  remarked  that  in  case  of  OldTahoe,  every  packet  loss  is  accompanied  by  a  timeout 
and  hence  =1  Vcr' 


5.3  Train  Probability  Calculation 

Proposition  3  Consider  TCP  Tahoe  or  TCP  OldTahoe.  Then  the  probabilities  of  the  different 
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trains  is  given  as 


P(ni  =  k/a)  =  (1  -  q;)^i+^2+-+0*-i  +  llE.  [1  _  _  ^2;;.]  0  <k  <tm 

1  —  a_ 

P{ni  =  t^/a)  =  (1  -  a)^i+^2+-+0t„-i  L  ^  ”  (26) 

L  1  —  a. 

where 

i>ij  =  7rG(l  -  a)^-’' 
i’2j  = 

tm  =  Wfn  —  oJ  +  \log2{aj)']  +  i  (27) 


Proof:  For  ni  to  be  k,  we  require  that  k  —  1  trains  experience  no  packet  loss  while  there  is  at 
least  one  packet  lost  in  the  A:th  train.  Since  the  number  of  packets  in  the  jth  train  is  given  to  be  6j, 
we  have  following  the  remarks  made  in  the  proof  of  the  loss  window  probability  calculation,  that 

P(ni  =  k/a)  =  (1  -  a)Si=i  ^  1  (7rB/3(l  -  a)“^) 

[i=i  \  i  J 

|l  —  7rG'(l  —  a)^*  —  7rB/3(l  —  a)^*“^|  0  <  k  <  tm 

r  /Q  1  k  —  1 

=  (1  —  a)Si=i  ttg  +  — ^ —  {l  —  7rG'(l  —  a)^*  —  7rB/3(l  —  a)^*“^|  (28) 

L  1  —  aj  •-  J 

When  k  =  tm,  a  packet  is  lost  from  the  tmt,h  train  with  probability  1  and  hence 

P{ni  =  tm/cj)  =  (1  -  [ttg  +  ”  (29) 

L  1  —  a. 

o 

Calculating  £^(ni)  given  the  above  probability  distribution  can  then  be  done  as 


E{ni)  =  E[E{nila)]  (30) 

^  j 

Remark:  tm  in  this  case  denotes  the  maximum  number  of  trains  possible  in  a  cycle. 
Remark:  Note  that  n2  =  0  w.p.  1  in  case  of  Tahoe/OldTahoe. 
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5.4  Packet  Count  Calculation 


Proposition  4  Consider  TCP  Tahoe  or  TCP  OldTahoe.  The  number  of  packets  during  a  cycle 
given  the  number  of  trains  and  the  loss  window  during  the  previous  cycle  is  given  by 

E{Qlni=k,a)  =  6i  +  62 -\ - 1-0^  0  <  k  <  tm  0  <  cr  <  Wm  (32) 

where 

01  =  1 

0j_i  =  <oj<  2^-^ei 

6j  =  u)  =  [cr/2j  where  j  =  \log2{uj)~\  +  1 
^j+l  ~  ^  0  <  I  ^  tm  ~  j 

Proof:  Note  that  every  cycle  of  Tahoe  starts  with  1  packet,  i.e.  61  =  1.  The  packets  in  a 
train  keep  on  doubling  as  long  as  the  window  size  is  less  than  the  slow  start  threshold.  Following 
this  the  number  of  packets  in  a  train  increases  by  one  in  each  successive  train.  Let  the  slow  start 
threshold  be  reached  in  the  jth  train.  Hence,  j  =  \log2{uj)~\  +  1  and  the  maximum  size  of  a  train 
is  Wm-  With  this  the  expressions  for  the  terms  given  above  as  well  as  for  E{Qlni,  a)  are  obvious. 

o 


6  Analytical  Study 

Now  that  the  loss  window  probability,  train  probability,  packet  count  and  the  timeout  probability 
are  specified,  we  use  these  expressions  in  equations  4  and  10  to  calculate  the  throughput  using 
equation  3.  Since  it  is  difficult  to  obtain  a  closed  form  solution  for  the  throughput  we  graph  the 
different  expressions  given  in  order  to  obtain  an  understanding  of  the  way  TCP  versions  work 
over  a  wireless  link  with  correlated  losses.  While  in  the  earlier  section,  expressions  only  in  case  of 
Tahoe  are  specified,  we  do  consider  all  the  TCP  algorithms  namely  OldTahoe,  Tahoe,  NewReno 
and  Sack  in  this  section.  The  different  parameters  that  we  consider  while  studying  the  behavior  of 
the  TCP  versions  under  correlated  losses  are  a,  /3,  packet  size  S  (bits),  link  bandwidth  jj,  (Mbps), 
timeout  value  (s),  rtt  T  (s)  and  the  fast  retransmit  threshold  12  (packets).  The  default  values  of 
the  parameters  are  S  =  125bytes,  timeout  granularity  of  0.5  seconds  for  coarse  timeout  and  0.05 
seconds  for  fine  timeout  [10]  while  12  =  3  unless  otherwise  specified. 
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Correlated  losses  over  a  2Mbps  link  with  0.01  s  rtt,  beta=0.1 


Figure  2:  Behavior  of  different  TCP  algorithms  with  correlated  packet  loss  model  under  bursty  loss 
conditions  over  a  link  with  a  bandwidth  delay  product  of  20  packets 

Before  proceeding,  we  next  obtain  approximate  conditions  under  which  random  packet  losses 
lead  to  significant  throughput  deterioration.  There  are  two  factors  that  have  to  be  taken  into 
consideration.  The  first  is  a  which  governs  the  maximum  window  size  possible  in  each  cycle.  The 
second  factor  is  (3  which  governs  the  probability  of  a  timeout. 

Concentrating  on  the  first  factor,  every  cycle  can  have  atmost  tm  trains  which  is  a  function  of 
Wm  and  a.  The  duration  of  each  train  is  T  seconds  which  is  the  rtt.  Hence  for  good  performance, 
noting  that  the  duration  of  each  slot  equals  the  transmission  time  of  a  packet,  we  require 

~  >  tTO-T'.number  of  packets  transmitted  per  unit  time 

a 

>  tmTjJ.  (33) 

This  follows  since  the  reciprocal  of  a  denotes  the  mean  number  of  successful  packets  in  a  cycle  and 
we  desire  that  the  mean  duration  of  the  good  period  exceed  the  duration  of  an  entire  cycle.  It 
is  quite  obvious  that  by  ensuring  this,  not  only  does  the  window  grow  to  the  maximum  possible 
size  Wm,  but  also  the  next  cycle  begins  with  a  high  slow-start  threshold  which  is  desirable.  Now, 
since  tm  is  proportional  to  Wm,  approximating  tm  by  Wm,  we  have  a  necessary  condition  for  good 
behavior  that 

-  >  {pTf 
a 
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Correlated  losses  over  a  2Mbps  link  with  0.01  s  rtt,  beta=0.9 


Figure  3:  Illustration  of  the  effects  of  non-bursty  loss  conditions  showing  much  performance  im¬ 
provement  compared  to  the  bursty  loss  conditions 

Looking  at  the  second  factor  next,  for  good  performance  a  necessary  condition  is  that 

This  follows  since  the  reciprocal  of  (3  denotes  the  mean  number  of  packets  lost  in  the  loss  window. 
If  this  is  comparable  to  the  size  of  the  loss  window,  then  it  will  result  in  a  timeout  which  has  to  be 
avoided  for  good  performance.  Hence,  we  require  that  this  quantity  be  smaller  than  the  average 
window  size  assuming  that  the  window  can  grow  to  it’s  maximum  possible  values.  It  has  to  be 
remarked  here  that  this  condition  would  not  be  necessary  if  the  connection  is  using  fine  timeout 
values  since  in  that  case  the  effect  of  a  timeout  is  not  severe  at  all.  As  we  see  later,  for  all  the 
scenarios  considered  both  the  above  conditions  are  necessary  to  ensure  good  link  utilization. 

Now,  consider  figure  2  which  illustrates  the  performance  of  a  wireless  link  with  a  bandwidth 
of  2Mbps  and  an  rtt  of  0.01s.  (3  is  assumed  to  be  0.1  while  a  is  varied  and  shown  on  the  x-axis. 
The  throughput  normalized  to  the  link  bandwidth  is  shown  on  the  y-axis.  Similar  scenarios  with 
(3  =  0.9  is  shown  in  figure  3.  As  can  be  seen  from  these  figures  as  the  value  of  (3  increases  ,  the 
performance  of  the  different  TCP  algorithms  (except  OldTahoe)  also  improves.  Also  as  a  increases, 
the  performance  of  all  the  algorithms  decreases.  Note  that  the  reciprocal  of  (3  gives  the  average 
number  of  packets  lost  while  the  reciprocal  of  a  gives  the  average  number  of  good  packets.  Hence, 
as  (3  increases,  the  probability  of  timeout  decreases  and  the  performance  is  hence  better.  But  since 
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Correlated  losses  over  a  1  Mbps  link  with  0.05s  rtt,  beta=0.1 


Figure  4:  Performance  of  TCP  versions  under  very  bursty  conditions  showing  significant  perfor¬ 
mance  improvement  at  low  a  for  a  higher  bandwidth- delay  product  of  50  packets  with  (3  =  0.1 

OldTahoe  always  depends  on  a  timeout  to  infer  packet  loss,  there  is  no  performance  improvement 
in  contrast  to  the  other  TCP  versions.  At  moderate  values  of  /3,  there  are  more  chances  of  multiple 
packet  drops  in  a  window  while  at  high  values  of  (3  around  1,  generally  only  single  packet  drops 
occur. 
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18 

4 

4.25 

22 

22 

19 

4 

4.5 

23,24,25,26 

Table  6a:  Evolution  of  Tahoe  when  packets  15-19  are  lost  taking  3  rtts  to  recover  the  lost  packets 
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1  Mbps  link  with  0.02s  rtt,  beta=0.1  and  fine  timeout 


Figure  5:  Illustrating  that  at  low  values  of  (3  the  performance  depends  only  on  the  bandwidth- delay 
product  when  using  a  fine  timeout  interval 
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22  (Par  ack) 
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4 

4 

23,24,25,26 

Table  6b:  Fast  Recovery  for  New  Reno  when  packets  15-19  (inclusive)  are  lost  taking  5  rtts  to 

recover  the  lost  packets 


Another  important  observation  from  these  figures  is  also  that  for  low  values  of  /3,  NewReno 
performs  worse  than  Tahoe.  This  is  because  of  the  nature  of  NewReno  of  taking  one  rtt  to  recover 
each  lost  packet  which  leads  to  a  smaller  throughput  than  achievable  by  Tahoe.  For  e.g.  in  a 
window  of  10  as  in  these  figures,  assuming  5  bursty  packet  losses  (read  5  consecutive  packets  lost) 
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Figure  6:  Illustrating  that  at  low  values  of  (3  the  performance  depends  only  on  the  bandwidth- delay 
product  when  using  a  fine  timeout  interval 


in  a  loss  window  of  9  or  more  a  timeout  does  not  occur  since  there  are  enough  successful  packets  to 
inform  the  sender  of  packet  losses  through  the  duplicate  ack  mechanism.  In  this  scenario  NewReno 
takes  5  rtts  to  recover  from  these  5  packet  losses  by  sending  one  lost  and  utmost  two  packets  in  each 
rtt.  In  contrast,  Tahoe  by  resorting  to  slow  start  recovers  these  packets  more  efficiently  by  sending 
more  number  of  packets  on  the  average.  We  show  an  example  of  one  such  possibility  in  Table  6a 
and  6b.  As  shown,  when  5  consecutive  packets  15-19  are  lost,  Tahoe  recovers  these  packets  within 
3  rtts  while  NewReno  takes  5  rtts  to  recover  these  packets  thereby  causing  a  higher  inefficiency 
in  the  link  utilization.  Of  course  the  drawback  may  be  that  Tahoe  had  had  to  retransmit  some 
packets  unneccessarily  but  yet  in  terms  of  throughput  the  Tahoe  sender  is  more  efficient  than  the 
NewReno  sender.  Thus  Tahoe  is  able  to  send  14  packets  not  present  at  the  receiver  during  these  5 
rtts  while  NewReno  is  able  to  send  only  5  packets  not  present  at  the  receiver  during  these  5  rtts. 
Of  course.  Sack  by  virtue  of  the  selective  ack  option  recovers  most  efficiently  and  hence  exhibits 
the  best  performance.  Note  also  that  as  the  maximum  possible  window  size  (Wm)  grows  larger,  the 
performance  of  NewReno  lags  the  performance  of  Tahoe  by  a  larger  degree.  We  see  this  later  in 
figure  4  and  10.  This  is  because  the  size  of  the  bursts  may  not  be  enough  to  cause  a  timeout  due  to 
the  large  loss  window  leading  to  lost  packet  recovery  through  the  inefficient  fast  recovery  method 
of  NewReno.  As  a  corollary  this  implies  that  at  higher  values  of  a,  performance  of  NewReno  can 
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2Mbps  link  with  0.01s  rtt,  beta=0.1  and  1  dup  ack 


Figure  7:  Illustrating  that  reducing  the  fast  retransmit  threshold  has  a  marginal  effect  in  the  regime 
of  low  (3 

be  better  compared  to  the  performance  of  Tahoe  since  at  high  values  of  a  the  maximum  possible 
value  to  which  the  window  can  grow  to  is  limited,  thereby  masking  the  weakness  of  NewReno’s  fast 
recovery  mechanism.  We  can  observe  this  from  figure  2. 

It  is  to  be  remarked  here  that  if  packet  losses  were  more  staggered  like  in  the  iid  model,  NewReno 
while  being  constrained  to  send  at  most  one  lost  packet  per  rtt,  can  also  send  more  than  two  packets 
per  rtt.  This  plus  the  nature  of  Tahoe  of  retransmitting  even  the  packets  successfully  received  in 
such  a  scenario  ensures  that  the  performance  of  NewReno  is  better  than  the  performance  of  Tahoe  in 
an  iid  loss  regime  (causing  staggered  packet  losses).  We  remark  here  that  it  can  be  seen  from  these 
figures  that  the  link  utilization  achieves  the  maximum  possible  for  the  concerned  TCP  algorithm 
whenever  the  necessary  conditions  derived  earlier  are  satisfied.  Note  that  with  a  link  bandwidth 
delay  of  20  packets,  the  two  necessary  conditions  for  good  performance  translate  into  a  <  0.0025 
and  P  >  0.1. 

Figure  4  considers  a  wireless  link  with  a  bandwidth  of  1Mbps  and  0.05s  rtt.  Thus  the  two 
conditions  for  a  bandwidth  delay  product  of  50  packets  translate  into  a  <  .0004  and  /3  >  0.04.  The 
same  observations  made  earlier  hold  in  this  case,  the  most  notable  being  that  the  performance  of 
NewReno  is  worst  than  that  of  Tahoe  under  very  bursty  loss  conditions  (read  /3  around  0.1  and 
lower)  at  higher  bandwidth  delay  products  as  expected.  Further  from  these  figures  it  can  also  be 
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2Mbps  link  with  0.01s  rtt,  beta=0.9  and  1  dup  ack 


Figure  8:  Illustrating  that  reducing  the  fast  retransmit  threshold  has  a  significant  effect  in  the  regime 
of  high  (3  only  for  high  a  values 

seen  that  the  normalized  throughput  becomes  better  for  low  values  of  (3  as  the  rtt  increases.  This 
is  because  of  the  large  bandwidth-delay  product  link  which  implies  that  even  with  (3  =  0.1,  the 
chances  of  an  entire  window  of  packets  being  dropped  for  window  sizes  high  enough  are  quite  low. 
Further,  the  timeout  duration  also  becomes  a  smaller  multiple  of  the  rtt  as  the  rtt  increases  and 
hence  the  use  of  coarse  timeout  becomes  less  significant.  Note  that  this  effect  is  predominant  only 
with  low  values  of  (3  as  can  be  seen  from  figures  2  and  4.  Thus,  it  can  be  inferred  that  at  low  values 
of  (3  the  performance  does  not  depend  on  just  the  bandwidth-delay  product  but  also  on  the  value  of 
the  rtt.  This  is  not  the  case  for  high  values  of  /3.  This  is  because  at  high  (3  values  Tahoe,  NewReno 
and  Sack  experience  timeouts  very  infrequently  leading  to  insensitivity  to  the  granularity  of  the 
timeout  interval.  Thus  it  can  also  be  expected  and  it  has  also  been  verified  that  at  relatively  high 
values  of  (3,  fine  timeout  does  not  make  much  of  a  difference  compared  with  the  coarse  timeout. 

To  show  that  the  performance  difference  is  indeed  due  to  the  coarse  timeout  granularity  for  low 
values  of  (3,  in  figures  5  and  6  we  consider  link  bandwidths  of  1  Mbps  and  2  Mbps  respectively  while 
ensuring  that  the  bandwidth  delay  products  remain  the  same  at  20  packets  by  properly  choosing  the 
rtt  values.  Comparing  these  two  figures,  it  can  be  seen  that  the  performance  of  the  different  TCP 
versions  is  nearly  similar  with  the  performance  becoming  identical  as  the  timeout  granularity  is 
decreased  further.  Comparing  figure  6  with  figure  2,  the  performance  improvement  for  the  different 
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Correlated  losses  over  a  1  Mbps,  0.05s  rtt  link  alpha=0.0001 


Figure  9:  Illustrating  the  effects  of  varying  f3  for  a  link  with  a  bandwidth- delay  product  of  50  packets 

TCP  versions  using  a  fine  timeout  is  obvious.  Another  point  to  be  noted  is  that  as  the  granularity 
of  the  timeout  interval  becomes  finer  and  less  significant  with  respect  to  the  rtt,  the  behavior  gap 
of  Tahoe  and  OldTahoe  decreases  and  hence  NewReno  exhibits  the  worst  performance  of  all  the 
TCP  versions  as  expected  in  this  regime.  This  is  also  seen  in  figures  5  and  10.  Validity  of  our 
earlier  remark  that  while  using  fine  timeouts  the  second  condition  is  not  important  is  also  proven 
by  looking  at  these  figures. 

Effects  of  changing  the  fast  retransmit  threshold  from  3  to  1  are  shown  in  figures  7  and  8  with 
values  of  (3  being  0.1  and  0.9  respectively.  Comparing  these  with  figures  2  and  3  it  can  be  seen 
that  at  low  values  of  /3,  the  reduction  in  the  fast  retransmit  threshold  improves  the  performance 
marginally  only  at  low  a  values.  At  high  a  and  low  (3  values  the  threshold  reduction  does  not  lead 
to  a  significant  performance  change  since  in  this  regime  small  windows  and  large  bursts  are  the 
norm.  Prom  figures  3  and  8  it  can  be  seen  that  the  lower  threshold  makes  a  significant  difference 
only  at  high  values  of  a.  Thus,  the  threshold  reduction  makes  a  significant  difference  only  in  the 
regime  of  small  window  values  and  small  bursts  (big  a  and  big  /3).  In  the  other  regimes  the  effect  is 
not  that  significant.  Hence  going  for  a  reduction  in  threshold  may  not  be  that  good  an  idea  unless 
this  is  accompanied  by  some  way  to  sense  the  state  of  the  channel.  Note  also  that  a  threshold  of 
one  is  not  robust  to  packet  reordering  by  the  network.  So  the  option  of  reducing  the  fast  retransmit 
threshold  if  chosen  would  have  to  be  done  with  care. 
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Correlated  losses  over  a  2Mbps,  0.05s  rtt  link  alpha=0.0001 


Figure  10:  Illustrating  the  effects  of  varying  f3  for  a  link  with  a  bandwidth- delay  product  of  100 
packets 

We  next  investigate  the  effects  of  (3  while  keeping  a  constant.  Since,  these  results  can  only 
enhance  some  of  the  conclusions  drawn  earlier,  we  just  look  at  two  scenarios.  These  are  shown  in 
figures  9  and  10.  In  figure  9,  we  consider  a  scenario  with  a  bandwidth-delay  product  of  50  packets 
and  a  wireless  link  bandwidth  of  1Mbps.  At  very  low  values  of  /3,  timeouts  are  the  norm  and 
hence  the  performance  of  all  TCP  versions  is  similar.  The  robustness  of  Sack  and  Tahoe  to  values 
of  (3  above  a  threshold  as  remarked  earlier  is  also  seen.  This  is  because  Sack  and  Tahoe  recover 
the  same  way  for  single  and  multiple  packet  drops  (with  Sack  resorting  to  Fast  Recovery  in  both 
cases  and  Tahoe  going  through  slow  start  for  both  scenarios),  they  exhibit  similar  behavior  for 
both  moderate  and  high  values  of  /3.  In  contrast,  NewReno  recovers  from  multiple  packet  drops  by 
retransmitting  one  lost  packet  per  rtt  and  hence  it’s  behavior  improves  continually  as  (3  increases 
until  at  high  values  of  f3  the  performance  of  NewReno  and  Sack  becomes  very  similar.  From  figure 
10  which  considers  a  link  with  a  bandwidth  delay  product  of  100  packets  and  a  link  bandwidth  of 
2Mbps,  it  can  be  seen  that  the  minimum  robustness  threshold  decreases  as  the  bandwidth-delay 
product  increases.  The  performance  of  NewReno  though  is  very  sensitive  to  the  value  of  /3.  It  can 
also  be  seen  that  at  high  values  of  the  rtt  with  a  corresponding  high  value  of  the  bandwidth  delay 
product,  the  performance  of  NewReno  is  also  the  worst  of  all  the  TCP  versions  under  bursty  loss 
conditions  as  mentioned  earlier.  The  performance  is  also  seen  to  become  better  when  (3  >  0.02 
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since  a  <  0.0001  which  are  the  two  conditions  for  a  link  with  a  bandwidth  delay  of  100. 

7  Conclusion 

In  this  paper  we  have  looked  at  the  behavior  of  the  different  TCP  algorithms  over  a  wireless  channel 
with  correlated  packet  losses.  We  first  provide  an  analytical  model  for  studying  the  performance  of 
the  different  TCP  algorithms  namely  OldTahoe,  Tahoe,  NewReno  and  Sack  operating  over  a  wireless 
link  with  correlated  packet  losses.  We  then  provide  conditions  on  the  wireless  channel  satisfaction 
of  which  ensures  that  the  throughput  of  the  TCP  algorithm  tends  to  the  best  possible  throughput. 
We  see  that  the  behavior  of  Sack  is  the  best  in  all  regimes.  Another  important  result  that  we  have 
shown  is  that  for  situations  of  even  moderately  bursty  losses  the  performance  of  NewReno  is  worse 
than  Tahoe  with  performance  gap  widening  with  higher  values  of  Wm-  This  is  a  serious  flaw  in 
the  performance  of  NewReno  which  also  argues  for  the  widespread  implementation  of  Sack.  Also 
at  values  of  high  a,  the  performance  difference  between  the  different  versions  decreases  with  the 
difference  becoming  insignificant  as  the  value  of  j3  decreases.  It  is  also  seen  that  Sack  and  Tahoe 
are  insensitive  to  the  value  of  j3  as  long  as  j3  is  not  low  enough  while  NewReno’s  performance 
improves  continually  as  j3  increases.  This  implies  that  Sack  and  Tahoe  are  less  sensitive  to  the 
bursty  conditions  above  a  certain  threshold. 

We  have  also  shown  that  performance  of  the  different  TCP  versions  under  correlated  packet 
loss  depends  not  only  on  the  bandwidth  delay  product  but  also  on  the  granularity  of  the  timeout 
timer  for  low  values  of  /3.  For  high  values  of  j3  the  performance  depends  just  on  the  bandwidth 
delay  product.  Further,  it  is  also  seen  that  reducing  the  granularity  of  the  timeout  interval  as  also 
reducing  the  value  of  the  fast  retransmit  threshold  makes  a  difference  only  in  case  of  very  bursty 
loss  conditions  and  in  scenarios  where  the  window  cannot  grow  to  large  sizes  for  high  values  of 
P.  We  have  also  shown  that  at  very  high  bursty  loss  conditions  the  performance  of  all  the  TCP 
versions  is  similar. 
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